Moving formalFiles directory

We have menu-generating code in the formalFiles directory, which shows certain menu items based on user name and/or group membership. This works currently as all users run their DOORS clients on the same machine via remote desktop.

We have been asked to add a number of users who will be connecting with locally (to them) configured clients. To make this work, we'll need to move the contents of formalFiles to a network share and reconfigure DOORS clients.

The new users have relatively clean installs, conflicts are not an immediate cause of concern.

However, we are weary of changing the registry setting HKEY_LOCAL_MACHINE\SOFTWARE\Telelogic\DOORS\9.1\Config\Home - which is apparently what we need to do, to point everyone to a new formalFiles location. We expect that such a change will affect many other aspects of the installation, leading to all kinds of trouble.

Is there a more specific setting for just the dxl/config directory that we haven't discovered?

Are there any other ways to configure conditional creation of menu entries, e.g. in addins (which does seem to have a specific setting)?

Thanks for any input provided.
SystemAdmin - Mon Nov 15 05:42:38 EST 2010

Re: Moving formalFiles directory
Mathias Mamsch - Mon Nov 15 12:09:26 EST 2010

I don't know of such a switch. Is there any technical reason that would prevent you from doing the patch at your local configured clients? If this is about changing the menu script from time to time, you could once deploy a local file at the users computers that just contains:
  

// put this to your formalFiles directory of your users pcs instead of the actual code
#include <\\server\path\to\custom\menu\file>

 


which will make the clients get a fresh menu file every time the client starts up. Maybe this helps! Regards, Mathias

 

 

 

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

 

 

Re: Moving formalFiles directory
SystemAdmin - Mon Nov 15 17:30:24 EST 2010

Mathias Mamsch - Mon Nov 15 12:09:26 EST 2010

I don't know of such a switch. Is there any technical reason that would prevent you from doing the patch at your local configured clients? If this is about changing the menu script from time to time, you could once deploy a local file at the users computers that just contains:
  

// put this to your formalFiles directory of your users pcs instead of the actual code
#include <\\server\path\to\custom\menu\file>

 


which will make the clients get a fresh menu file every time the client starts up. Maybe this helps! Regards, Mathias

 

 

 

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

 

 

I've never fully understood this - when it comes to inserting custom menu's, what is the difference between using the addins method where you use registry keys to point to where DXL menu code resides, and via the lib/dxl/config/formalfiles folder area which is called up in the formal.dxl file. Are there specific benefits?

Paul Miller

Re: Moving formalFiles directory
SystemAdmin - Tue Nov 16 03:49:36 EST 2010

Mathias Mamsch - Mon Nov 15 12:09:26 EST 2010

I don't know of such a switch. Is there any technical reason that would prevent you from doing the patch at your local configured clients? If this is about changing the menu script from time to time, you could once deploy a local file at the users computers that just contains:
  

// put this to your formalFiles directory of your users pcs instead of the actual code
#include <\\server\path\to\custom\menu\file>

 


which will make the clients get a fresh menu file every time the client starts up. Maybe this helps! Regards, Mathias

 

 

 

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

 

  

Is there any technical reason that would prevent you from doing 
the patch at your local configured clients?


Setting registry entries is possible through DXL, so a module trigger could automate the process. That would ease integration of current as well as new clients.

Re: Moving formalFiles directory
SystemAdmin - Tue Nov 16 03:51:37 EST 2010

SystemAdmin - Mon Nov 15 17:30:24 EST 2010
I've never fully understood this - when it comes to inserting custom menu's, what is the difference between using the addins method where you use registry keys to point to where DXL menu code resides, and via the lib/dxl/config/formalfiles folder area which is called up in the formal.dxl file. Are there specific benefits?

Paul Miller

> PRM wrote:
> I've never fully understood this - when it comes to inserting custom menu's, what is the difference between using the addins method where you use registry keys to point to where DXL menu code resides, and via the lib/dxl/config/formalfiles folder area which is called up in the formal.dxl file. Are there specific benefits?
>
>
> Paul Miller

In my (limited) experience:

The formalFiles method gives you more control, as an example we have menu entries which are only shown to a select group of users.

The addins method is much easier to configure and maintain.

Re: Moving formalFiles directory
Mathias Mamsch - Tue Nov 16 04:11:28 EST 2010

SystemAdmin - Mon Nov 15 17:30:24 EST 2010
I've never fully understood this - when it comes to inserting custom menu's, what is the difference between using the addins method where you use registry keys to point to where DXL menu code resides, and via the lib/dxl/config/formalfiles folder area which is called up in the formal.dxl file. Are there specific benefits?

Paul Miller

During startup of DOORS and during the opening of module DOORS will execute the code in lib/dxl/config/formal.dxl. In this unencrypted dxl file all menus of a formal module are created, you can make adaptions, like replacing the filter dialog or stuff like that. Creating menu items in your formal module is only possible during this opening phase, i.e. you cannot adapt the menus afterwards. In this file the folders for custom menu entries are evaluated:
  

...
autoRunDXLFolder("lib/dxl/config/formalPopupFiles")
...
autoRunDXLFolder("lib/dxl/config/formalfiles")
...

 


The same is true for the database explorer, which is evaluated on DOORS startup. Configuring menus is done using the createMenuItem function which allows you to specify a callback function that will determine in what cases the menu item shall be visible or disabled. This way the menus can react flexibly to the current state of your module, e.g. gray out "Start Link" when the module is opened read only and stuff like this. Hope that helps, regards, Mathias

 

 

 

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

 

 

Re: Moving formalFiles directory
SystemAdmin - Tue Nov 16 20:55:09 EST 2010

Mathias Mamsch - Tue Nov 16 04:11:28 EST 2010

During startup of DOORS and during the opening of module DOORS will execute the code in lib/dxl/config/formal.dxl. In this unencrypted dxl file all menus of a formal module are created, you can make adaptions, like replacing the filter dialog or stuff like that. Creating menu items in your formal module is only possible during this opening phase, i.e. you cannot adapt the menus afterwards. In this file the folders for custom menu entries are evaluated:
  

...
autoRunDXLFolder("lib/dxl/config/formalPopupFiles")
...
autoRunDXLFolder("lib/dxl/config/formalfiles")
...

 


The same is true for the database explorer, which is evaluated on DOORS startup. Configuring menus is done using the createMenuItem function which allows you to specify a callback function that will determine in what cases the menu item shall be visible or disabled. This way the menus can react flexibly to the current state of your module, e.g. gray out "Start Link" when the module is opened read only and stuff like this. Hope that helps, regards, Mathias

 

 

 

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

 

 

Thanks Mathias - but I still can't see what the advantage\benefit is in doing it this way. Module and Explorer level menu's can also be embedded using the Addins method as well.

cpedersen responded with "...The formalFiles method gives you more control, as an example we have menu entries which are only shown to a select group of users..."

Control of user level access to custom menu items can also be achieved with the Addins method - so are there any other benefits\Uses that the Addins method cannot provide?

Paul Miller

Re: Moving formalFiles directory
Mathias Mamsch - Wed Nov 17 03:22:54 EST 2010

SystemAdmin - Tue Nov 16 20:55:09 EST 2010
Thanks Mathias - but I still can't see what the advantage\benefit is in doing it this way. Module and Explorer level menu's can also be embedded using the Addins method as well.

cpedersen responded with "...The formalFiles method gives you more control, as an example we have menu entries which are only shown to a select group of users..."

Control of user level access to custom menu items can also be achieved with the Addins method - so are there any other benefits\Uses that the Addins method cannot provide?

Paul Miller

What you can do using this method is:

  • have different menus for different module types (using addins all formal modules will have the same menu)
  • Even if you are not using active directory but DOORS access rights, you can make menus appear/disappear depending on group membership of users or any other more complex decision (e.g. if the state of the module = "in review" -> display the review menu).
  • activate and deactivate menu items (using addins you can only have active menu items, which will have to report an error end end itself, when it shall not be run)
  • faster menu creation (using addins all DXL files in a folder will be parsed and be checked for comments at the beginning. this can be really increase module startup times over a slow network, when you got huge menus).
  • You can do extend the popup menus in link modules / formal modules
  • You can define symbol bars for your modules.
  • You can modify existing menu items of DOORS

Summing up:
  • addins/projectaddins at startup = static menus
  • using formalfiles, etc. = dynamic menus

I personally have never had the need to use dynamic menus, but in certain situations their flexibility can really improve user experience.

Regards, Mathias

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

Re: Moving formalFiles directory
SystemAdmin - Thu Nov 18 19:13:46 EST 2010

Mathias Mamsch - Wed Nov 17 03:22:54 EST 2010
What you can do using this method is:

  • have different menus for different module types (using addins all formal modules will have the same menu)
  • Even if you are not using active directory but DOORS access rights, you can make menus appear/disappear depending on group membership of users or any other more complex decision (e.g. if the state of the module = "in review" -> display the review menu).
  • activate and deactivate menu items (using addins you can only have active menu items, which will have to report an error end end itself, when it shall not be run)
  • faster menu creation (using addins all DXL files in a folder will be parsed and be checked for comments at the beginning. this can be really increase module startup times over a slow network, when you got huge menus).
  • You can do extend the popup menus in link modules / formal modules
  • You can define symbol bars for your modules.
  • You can modify existing menu items of DOORS

Summing up:
  • addins/projectaddins at startup = static menus
  • using formalfiles, etc. = dynamic menus

I personally have never had the need to use dynamic menus, but in certain situations their flexibility can really improve user experience.

Regards, Mathias

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

Excellent Mathias - now I understand the key differences.

Paul Miller